home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 2901 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.6 KB
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.misc
  4. Subject: Re: OS features
  5. Date: 24 Jan 1996 23:17:29 +0100
  6. Organization: dis-
  7. Message-ID: <4e6b5p$aet@serpens.rhein.de>
  8. References: <4aj1tc$39r@candelo.dpie.gov.au> <13213430@sourcery.han.de> <wfblanDL60p0.D0y@netcom.com> <1058.6591T492T1743@cycor.ca> <DLnqBB.DuD@focus-systems.on.ca> <4e442t$4ve@serpens.rhein.de> <4e657d$2db@news.rhrz.uni-bonn.de>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. fasten@zeus.informatik.uni-bonn.de (Bernhard Fastenrath) writes:
  12.  
  13. >Maybe not. Let's say (as you suggested earlier) that some subsystems
  14. >(e.g. Intuition) have the permission to read and write any memory region.
  15.  
  16. Not any region, just some regions from clients of the library.
  17.  
  18. >Intuition functions would have to check if the pointers received from
  19. >process A point into A's memory and, of course, if they are consistent
  20. >and don't corrupt Intuition's internal data when used (That's a good piece
  21. >of work for the programmers and for Intuition at runtime but I guess it's
  22. >possible).
  23.  
  24. I guess it is not feasible because it is too much overhead.
  25.  
  26. >Programs which want to browse internal data structures of Intuition are
  27. >either given permission or fail.
  28.  
  29. This requires even finer protection spaces as you may want them to
  30. access _some_ Intuition data, even to _modify_ Intuition data but
  31. just not everything that Intuition manages.
  32.  
  33. >How about this: Write access to a data structure shared between a process
  34. >and Intutition marks the data structure as dirty and Intuition has to
  35. >perform consistency checks again before using it.
  36.  
  37. Even slower.
  38.  
  39. >Device drivers would have to be a subsystem with the license to kill
  40. >(read/write everything).
  41.  
  42. One possibility but that requires new drivers too because none of them
  43. check the buffer adresses passed to them.
  44.  
  45. >System hooks would be restricted to programs
  46. >which were given special permission.
  47.  
  48. Unfortunately the whole object oriented GUI consists of "system hooks".
  49.  
  50. >Old programs could use one address space and pass pointers as much as
  51. >they want to.
  52.  
  53. That's not really a solution. The end of this idea is to write a completely
  54. new OS and run AmigaOS as an emulation. I don't think that this is worth
  55. any effort.
  56.  
  57. >Maybe if A calls PutMsg() it gives the receiving process B
  58. >the permission to read/write its memory.
  59.  
  60. Can't be done with message granularity. Any communication would
  61. be again completely unprotected. Even more, any program can send
  62. messages to any other program this way.
  63.  
  64. >New programs could
  65. >also use PutMsg() but they'd allocate the message from a special pool
  66. >and the other task receives only read/write permission for this pool.
  67.  
  68. Yes. This has to be the way.
  69.  
  70. >The private memory of new programs wouldn't have to be in the global
  71. >address space.
  72.  
  73. Yes. But communication of old and new programs make this difficult. You
  74. need a geometric mapping (i.e. global address space is in the first 1GB,
  75. private addresses are in the second 1GB, or similar), otherwise you
  76. run into cases where communication is not possible because address spaces
  77. overlap.
  78.  
  79. >Another difference between old and new programs could be that the memory
  80. >of old programs must not be swapped while new programs can decide for
  81. >each of their pools if it has MEMF_SWAP set or not.
  82.  
  83. I suggest that old program can be tagged to allow some or all of their
  84. segments and memory allocations to be swapped out.
  85.  
  86. >PS.: #define MEMF_PUBLIC 0
  87.  
  88. Something like that, yes :)
  89.  
  90. -- 
  91.                                 Michael van Elst
  92.  
  93. Internet: mlelstv@serpens.rhein.de
  94.                                 "A potential Snark may lurk in every tree."
  95.